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REMARKS 

Claims 12, 13, 25-27 and 29 have been amended. Applicants reserve the right 
to pursue the original claims and other claims in this application and other applications. 
Claims 12-15, 18-27, 29-32, 42 and 43 are pending in this application. 

The specification stands objected to as failing to provide proper antecedent basis 
for the claimed subject matter with respect to claim 25. The Office Action contends that 
the means for processing a first audit record, a second audit record and usage data as 
recited in claim 25 do not have proper antecedent basis in the specification. 

Independent claim 25 includes the recitation of a controller. Fig. 1, item 44, and 
its corresponding description in paragraph [0018] specifically describes one or more 
controllers that is included in the data center 40. As expressly detailed above, the terms 
and phrases used in the claims find clear support in the written description. 

Claims 14 and 27 stand objected to as being of improper dependent form for 
failing to further limit the subject matter of a previous claim. Claims 14 and 27 have 
been amended to address the Examiner's concerns. 

Claims 12-15, 18-27, 29-32, 42 and 43 stand rejected under 35 U.S.C. §112, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. Claims 12 and 25 
have been amended to address the Examiner's concerns. 

Claims 25-27, 29-32 and 43 stand rejected under 35 U.S.C. §112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. The Office Action contends 
that it is unclear whether claim 25 is claiming a data center or a data center in 
combination with a dispensing device. The Office Action contends that the claim 
positively recites a dispensing device. Applicants respectfully disagree. Claim 25 is 
directed to a data center and positively recites an interface circuit that receives audit 
records and usage data from a dispensing device, and a controller coupled to the 
interface circuit that is configured to process the audit records and the usage data. 
Claim 25 does not positively recite the dispensing device. 
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Claims 25-27, 29-32 and 42 stand rejected under 35 U.S.C. §101 as being 
directed to non-statutory subject matter. Claim 25 has been amended and is now 
clearly directed to statutory subject matter. 

Claims 12, 18-25, 29-32, 42 and 43 stand rejected under 35 U.S.C. § 102(e) as 
being anticipated by Leon (US 6,424,954). Claims 13-15 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over Leon in view of Mosher (US 5,799,322). 
Reconsideration is respectfully requested. 

As noted in the current specification, in many instances it is desirable, or in some 
cases mandated by the postal authority, for value dispensing devices, e.g., postage 
meters, to maintain usage information. Such usage information can include, for 
example, the amount of postage dispensed by the meter, as well as other data, 
including, for example, total mail piece counts, piece counts for different classes of mail, 
piece counts for each different postage amount dispensed, etc. The usage information 
is typically compiled over a predetermined period of time, referred to as an audit period, 
such as, for example, weekly, monthly, or yearly. At the end of the determined audit 
period, the captured data for that audit period is transmitted to a data center, such as, 
for example, a data center operated by the meter manufacturer, where it is used to 
prepare reports. The prepared reports can be sent to the postal authority. These 
reports may then be utilized by the postal authorities (or the meter manufacturer) for 
such things, for example, as statistical analysis of use of the meter population, customer 
billing, etc. 

There are problems, however, with conventional systems and methods for 
preparing data capture reports for a given audit period. One such problem is that the 
data capture data is blindly trusted for preparation of a report. The data capture data, 
however, may not be fully trustworthy when received from the postage meter. For 
example, since the usage information is not securely stored within the device, it is 
possible for a dishonest person to modify the data capture data before it is transmitted 
to the meter manufacturer. For example, the value of the total amount of postage 
dispensed during the audit period could be modified in such a way that this value is 
made lower than the actual value used. In cases where the reports are used for billing 
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purposes, the postal authority would under bill the customer, based on the modified 
data capture report, and thus the postal authority would be defrauded of funds due. 

The present invention alleviates the problems associated with the prior art and 
provides a system and method that can detect tampering with data capture data, as well 
as verify the authenticity of data capture data, in a value dispensing system. At the 
beginning of an audit period, an audit record is generated by the postage meter that 
includes the current register values at the beginning of the audit period and a digital 
signature generated by the device. At the end of the audit period, a second audit record 
is generated by the postage meter that includes the register values at the end of the 
audit period and a digital signature generated by the device. This end of period audit 
record is then transmitted to the data center, along with the data capture data and the 
start of period audit record (if not previously transmitted to the data center). The data 
center, after obtaining both the end of period audit record and start of period audit 
record, will verify the digital signature of the both audit records. Successful verification 
of the digital signatures authenticates the device to the data center, and indicates that 
the register values are valid, as any modification of the data contained within the audit 
records would result in a failure of the signature verification. The data center can then 
reconcile the postage meter usage, i.e., register values, by comparing the difference 
between the register values from the start of period audit record and the end of period 
audit record with the values as contained within the data capture data for the audit 
period. Any discrepancies between these values indicate that the data capture data 
may not be correct, and a further investigation can be performed. If there are no 
discrepancies, the data capture data is deemed to be accurate and the data can be 
utilized to prepare reports with a high degree of certainty that it accurately reflects the 
actual usage of the postage meter. (See Specification, paragraphs [0022] through 
[0025]). 

In view of the above, claim 12 is directed to a method for a data center to 
process usage data of a value dispensing device that comprises "receiving a first audit 
record from the value dispensing device, the first audit record generated by the value 
dispensing device at a start of an audit period, the first audit record including a value of 
at least one register maintained by the value dispensing device at the start of the audit 
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period and a first digital signature; receiving a second audit record from the value 
dispensing device, the second audit record generated by the value dispensing device at 
an end of the audit period, the second audit record including a value of the at least one 
register maintained by the value dispensing device at the end of the audit period and a 
second digital signature; receiving usage data from the value dispensing device for the 
audit period; determining that the first and second digital signatures verify; determining 
a difference between the value of the at least one register at the end of the audit period 
and the start of the audit period; comparing the determined difference with 
corresponding data provided in the usage data; and if the determined difference 
correlates with the corresponding data provided in the usage data, generating a usage 
report for the value dispensing system based on the usage data." 

Leon, in contrast is directed to a postage metering system in which an audit 
transaction is performed periodically to reset a timer. If the timer times out before an 
audit transaction is performed, the secure metering device (SMD) transitions to a state 
in which no further operation (except for an audit transaction) is permitted. A user 
requests an audit causing the host PC to send an audit request message to the SMD. 
The SMD then sends the host PC a signed message that includes the required 
information, which can include the current contents of the secure revenue registers, the 
device ID number, the current date and time, and a transaction serial number generated 
by the SMD. The host PC forwards the signed message to a system server, which 
receives and validates the message. As part of the processing, the system server 
authenticates the signed message using the SMD's public key and analyzes the data 
included in the message. The system server then sends the host PC a signed message 
that includes the response data, including the same device ID and transaction number 
from the message received earlier. The host PC forwards this signed message to the 
SMD, which validates the message by verifying the signature and determining if the 
message is of an expected type. If the signature is valid and the message is of an 
expected typed, the SMD determines if the data contents of the message is correct by 
verifying the transaction serial number. If the data is valid, the SMD resets the timer 
and transitions to an operating state. (Col. 18, line 30 to Col. 19, linelS). 
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Thus, in Leon the system uses only a single audit record for the purpose of 
resetting a tinner. There is no disclosure, teaching or suggestion in Leon of "receiving a 
second audit record from the value dispensing device, the second audit record 
generated by the value dispensing device at an end of the audit period, the second 
audit record including a value of the at least one register maintained by the value 
dispensing device at the end of the audit period and a second digital signature" as is 
recited in claim 12. In Leon, there is no second audit record generated at the end of an 
audit period. The system in Leon uses only a single audit record taken at a specific 
point in time. The Office Action appears to be contending that the audit requests in 
Leon sent at the end of one period are also considered to be sent at the beginning of a 
subsequent period, and therefore this single audit request in Leon is the same as a first 
audit record generated at the start of an audit period and a second audit record 
generated at the end of the audit period. It is unclear how a single audit request in Leon 
is analogous to a first audit report and a second audit report that are generated at 
different times. There is no disclosure, teaching or suggestion in Leon of "receiving a 
first audit record from the value dispensing device, the first audit record generated by 
the value dispensing device at a start of an audit period, the first audit record including a 
value of at least one register maintained by the value dispensing device at the start of 
the audit period and a first digital signature; receiving a second audit record from the 
value dispensing device, the second audit record generated by the value dispensing 
device at an end of the audit period, the second audit record including a value of the at 
least one register maintained by the value dispensing device at the end of the audit 
period and a second digital signature" as is recited in claim 12. 

There is also no disclosure, teaching or suggestion in Leon of "receiving usage 
data from the value dispensing device for the audit period." While the messages in 
Leon may provide current information, there is nothing in Leon that describes any type 
of usage data for an audit period. The Office Action has not provided any indication as 
to where this feature is allegedly disclosed, taught or suggested in Leon. 

There is also no disclosure, teaching or suggestion in Leon of "determining a 
difference between the value of the at least one register at the end of the audit period 
and the start of the audit period." The Office Action contends that Col. 9, lines 11-20 
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and Col. 61, line 51 to Col. 62, line 13 of Leon disclose this feature. Col. 9, lines 11-20, 
of Leon are reproduced below. 

The SMD supports the provider role by providing 
the following services: Registration, Funding, Audit, 
and Withdrawal. These services are described in detail 
below. Whenever one of these services is requested, 
the SMD validates that the requester is an authorized 
provider. This is achieved by using the provider's 
public key to validate the signature on the service 
request that has been signed using the provider's 
private key. The provider's public key is retrieved 
from the Provider X.509 certificate that is loaded by 
the Crypto-Of f icer during initialization. 

There is nothing in this passage that discloses, teaches or suggests "determining 
a difference between the value of the at least one register at the end of the audit period 
and the start of the audit period." 

Col. 61 of Leon describes a message, processed during a funding transaction, 
which instructs the SMD to increase the value in the descending register, thereby 
increasing the SMD's revenue store. The message includes a type code that identifies 
the FUNDS message, followed by a Postage Value Download field that was sent to the 
host PC by the system server. The Postage Value Download field includes the device 
identification, a serial number identifying the particular secure transaction, a control total 
(ascending register plus descending register) and the value by which the descending 
register will be increased. Upon receipt of the FUND3 message, the SMD pads the 
PVD field as necessary under FIPS-180, and verifies the digital signature. If the 
signature is valid, the SMD checks the Transaction ID included in the PVD field against 
the Transaction ID included in the FUND2 message. If the IDs are not equal, the SMD 
responds by sending the host PC an ERROR message that includes an error code of 
TRANS_ID and returning to the operating state it occupied at the start of the Funding 
transaction. If the Transaction IDs are equal, the SMD compares the value included in 
the Control Total with the sum of the SMD's current Ascending and Descending 
registers plus the value included in the Funding Revenue field of the message. If the 
Control Total included in the message is not equal to the sum, the SMD has already 
processed this funding transaction or is in some other way unsynchronized with the 
system server, and does not update the Descending register. The SMD sends the host 
PC an ERROR message that includes a CONTROL error number and then transitions 
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to the Registered state. If the Control Total is equal to the sum, the SMD increases the 
value of the internally stored Descending register, and prepares and sends a FUND4 
message to the host PC. The SMD also records the Funding Revenue amount and the 
date and time of this Funding transaction, so it can report it as the previous values in the 
next Funding transaction. (Col. 61 , line 5 to Col. 62, line 44). Nowhere in the passages 
relied upon by the Office Action is there any disclosure, teaching or suggestion of 
determining a difference between the value of the at least one register at the end of the 
audit period and the start of the audit period. The funding transaction in Leon is not in 
any way related to any type of audit period, nor is it related to the audit transaction 
previously discussed. There are no first or second audit records generated at the start 
and end of an audit period, and there is no determination of a difference between the 
value of a register at the end of the audit period and the start of the audit period. 

There is also no disclosure, teaching or suggestion in Leon of "comparing the 
determined difference with corresponding data provided in the usage data" as is recited 
in claim 12. The Office Action contends that Col. 46, lines 48-54 and Col. 62, lines 4- 
13, disclose this feature. Col. 46, lines 48-54 of Leon are reproduced below. 

Upon receipt of an AUDITl message, the SMD 
creates a Device Audit field as shown below, signs it, 
and sends it to the host PC in the AUDIT2 message. The 
host PC sends this field to the system server as part 
of an Audit transaction. If the system server is able 
to verify the Device Audit field, the host PC sends an 
AUDITS message to the SMD. 

There is nothing in this passage that discloses, teaches or suggests "comparing 
the determined difference with corresponding data provided in the usage data" as is 
recited in claim 12. 

As described in Col. 62 of Leon, the SMD compares the value included in the 
Control Total of the FUNDS message with the sum of the SMD's current Ascending 
register and Descending registers plus the value included in the Funding Revenue field 
of the message. None of the values being compared in Leon are a determined 
difference (of the value of a register at the end of the audit period and the start of the 
audit period) or any type of corresponding data provided in the usage data. 
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There is also no disclosure, teaching or suggestion in Leon of generating a 
usage report for the value dispensing system based on the usage data if the determined 
difference correlates with the corresponding data provided in the usage data as is 
recited in claim 12. The Office Action contends that Fig. 8F and Col. 62, lines 14-43, 
disclose this feature. As described in Col. 39 of Leon, Fig. 8F shows a diagram of a 
device status screen 890. The Status Screen 890 displays information about the SMD 
and the user, which may be helpful for tracking and troubleshooting by the provider or 
U.S. Postal Service. Fig. 8F of Leon is reproduced below. 



Device Status 



THIS IS THE CURRENT STATUS OF THE POSTAGE DEVICE: 
This information is provided in case you need to contact Neopost 
Technical Support. Generally, you do not need to understand the 
significance of the fields listed below. 

0004000000001309 
Funded 
000000009150 
0000240850 
OOOOOOOB 
8052 
000000094544 
07-31-1998 17.46 43.00 
0000004444 
Unknown 
Unknown 
Unknov/n 



Device ID: 
Device Slate: 
Ascending Register: 
Descending Register; 
Cycle Count: 
Device Software Version: 
Licensing ZIP Code: 
Device Initialization Dale & Time: 
License ID: 

Maximum Indicium Value: 
Minimum Indicium Value: 
Audit Pending Status: 



The current status of the postage device is not the same as a usage report 
generated based on usage data. With respect to Col. 62, as stated in Col. 62, lines 14- 
43, of Leon, if the Control Total is equal to the sum, the SMD increases the value of the 
internally stored Descending register, and prepares and sends a FUND4 message to 
the host PC. The SMD also records the Funding Revenue amount and the date and 
time of this Funding transaction, so it can report it as the previous values in the next 
Funding transaction. Increasing the value of the descending register is not the same as 
generating a usage report based on usage data. Furthermore, the FUND4 message is 
not a usage report - it merely is a status message to indicate the status of the postage 
download. 
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For at least the above reasons, Applicants respectfully submit that claim 12 is 
allowable over the prior art of record. Claims 13-15, 18-24 and 42, dependent upon 
claim 12, are allowable along with claim 12 and on their own merits. 

Claim 25 includes limitations similar to those of claim 12. For the same reasons 
given above with respect to claim 12, Applicants respectfully submit that claim 25 is 
allowable over the prior art of record. Claims 26, 27, 29-32 and 43, dependent upon 
claim 25, are allowable along with claim 25 and on their own merits. 

In view of the foregoing amendments and remarks, it is respectfully submitted 
that all claims are in condition for allowance and favorable action thereon is requested. 

Please charge any additional fees that may be required or credit any 
overpayment to Deposit Account Number 16-1885. 



Respectfully submitted. 



/Brian A. Lemm/ 
Brian A. Lemm 

Reg. No. 43,748 
Attorney for Applicants 
Telephone (203) 924-3836 
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